Hi Steffen, I would add it to a network macro if you want every system to get it. Otherwise, just a generic macro which you assign to IP addresses should be okay too. Lastly, a platform specific macro would work well to ensure SPARC's get SPARC boot files and X86's get X86 specific boot files.
Thank you, Clay On Tue, 12 May 2009, Steffen Weiberle wrote: > On 05/12/09 16:31, Clay Baenziger wrote: >> Hi Steffen, >> [Sensitive data cut out] I don't see a BootFile response in the offer >> at all, which will cause the SPARC to try TFTP. For an example, my macro >> contains the following entries. You should see something similar in your >> offer for AI to work: >> BootSrvA=172.20.24.78 >> Rootpath="http://172.20.24.78:5555/var/ai/clay_ai_sparc" >> BootFile="http://172.20.24.78:5555/cgi-bin/wanboot-cgi" >> >> If you're running the Solaris DHCP server, looking at which macros are >> assigned to IP addresses via "pntadm -P <network IP>", and what macro >> definitions look like via "dhtadm -P" may provide some insight. >> >> Thank you, >> Clay > > I did all that stuff, correclty, I think. Had to do it by hand as the > generated output had a syntax error. > > # dhtadm -P > Name Type Value > ================================================== > dhcp_macro_0906sparc Macro > :BootSrvA=129.154.53.138:BootFile="http://192.164.53.138:5555/cgi-bin/wanboot-cgi":Rootpath="http://192.164.53.138:5555/export/aiserver/osol-0906-ai-sparc": > 10.1.14.128 Macro > :Subnet=255.255.255.192:Router=10.1.14.130:Broadcst=10.1.14.191: > ventnor Macro > :Include=Locale:Timeserv=10.1.14.171:LeaseTim=7200:LeaseNeg:DNSdmain="stw.east.sun.com":DNSserv=10.1.14.130: > Locale Macro :UTCoffst=-18000: > > Oh, I see the problem. I did not match the macro. > > Should I have added this to the main macro (in my case ventnor, which is the > system name) or to the 10.1.14.128 macro? I created a new macro. > > Steffen > >> >> On Tue, 12 May 2009, Steffen Weiberle wrote: >> >>> On 05/12/09 15:40, Clay Baenziger wrote: >>>> Hi Steffen, >>>> The snoop output of the DHCPRESPONSE would be useful. In particular I >>>> suspect you are receiving a bootfile record which is not of the form >>>> "http://<blah>" in which case the OBP will try TFTP instead of HTTP. >>>> Thank you, >>>> Clay > >