Kyle McDonald wrote: > Mike Gerdts wrote: >> On Nov 28, 2007 10:47 AM, Kyle McDonald <KMcDonald at egenera.com> wrote: >>> I haven't been able to get my x86 clients to pay any attention to these >>> options though. Another poster on this list mentioned that he had this >>> working late last yer/early this year but it broke when 'newboot' was >>> integrated? >>> >>> Why is it broken. When booted to the miniroot dhcpinfo can look up all >>> these options, so it's not that it's not available. >>> >>> Is this considered a bug? Is there an ID? >>> >>> Where would I look to fix it? Is /sbin/install-discovery the right place? >> I think that I am the other poster you refer to. I first raised this >> issue when a discussion of the new installation strategy was pretty >> young. Look where I talk about Page 11. >> >> http://mail.opensolaris.org/pipermail/install-discuss/2006-March/002459.html >> >> There was a little bit of follow-up saying that it was going to break >> on SPARC too. I have a starting point for getting dhcp to work again, >> but I am not sure that the instructions I gave there are complete. I >> think there is a step missing, but I forget what it is. It is easier >> to modify my jumpstart environment to generate the proper grub >> configuration than it is to customize the root file system images from >> time to time. >> > Yes I see the reply here: > >>/ / > >>/ Page 11 - DHCP, PXE, etc. In Update 1, vendor DHCP options for x86/ > >>/ became unsupported in favor of maintaining those in menu.lst files. / > >>/ Note that there was no EOF announcement to help customers prepare for/ > >>/ this change and that all of the required functionality is still in the/ > >>/ miniroot that is TFTP'd. Turning /sbin/dhcpinfo into a wrapper that/ > >>/ does "if [ some_condition] ; then ifconfig bge0 dhcp primary ; fi ;/ > >>/ exec /sbin/dhcpinfo.orig" brings this feature back. This change seems/ > >>/ completely unnecessary and only serves to fragement x86 and SPARC/ > >>/ jumpstart environments. Did I mention there was no EOF announcement/ > >>/ and only one off-handed mention in the release notes?/ > >>/ / > > > > I expect we'll fix the fragmentation between x86 and SPARC by going to > > GRUB on SPARC as well. Long term, I think the model is better for most > > people, but the transition could have been handled better, I agree. > > > > First, Mike mentions that there was no EOF announcement for this removal > on x86?. Was there an ARC case? is it public? >
PSARC/2004/454 Solaris Boot Architecture. It's not public. > Second, I have to ask 'Why?' > > Why take this step backwards? > > Even if it is doable in the grub menu.lst file, why put it there if you > don't have to? It doesn't really make sense there. It makes that file > very unreadable and unwieldy. Why give up the more flexible and better > design you've already put work into? Was there a technical reason that > this had to be done? > [ The below shouldn't be read as defending, merely explaining] I wouldn't say there's any technical reason it had to be done, much of it had to do with resource and priority calls. One thing that we've learned over the years is that DHCP didn't turn out to be a particularly good install automation technology for a lot (seemingly the majority) of customers, because in so many sites the DHCP infrastructure is managed by a completely different organization from the Solaris infrastructure. It's all too often managed by either the network managers or the Windows managers, and neither is typically interested in supporting custom configurations for Solaris systems. If anything, a lot of the SPARC customers have asked that we actually support the OBP-level setting of networking and so on that we use for WAN installation on the ordinary LAN case (which is why I've planned to do so as part of Caiman). Even if you use DHCP, the percentage of sites which used the Solaris server as opposed to ISC, Windows, Cisco, or Lucent (just to name the ones I'm most aware of) was never all that high and has been dropping as we've not invested to improve it. x86-oriented environments in particular seemed highly unlikely to be choosing the Solaris DHCP server. Thus when it came time to figure out how to handle the transition to GRUB, it seemed that leveraging the menu.lst was a high priority, since it provided an equivalence to the OBP WAN installation options, and anything else was likely to be significantly less popular. Resolving precedence between command-line and DHCP sources just wasn't something that there was time for, as I recall, though my memory may be faulty on that front. Anyway, that's the history as best I remember. Sarah is in the early stages of investigating what we'll do for automated installs in Caiman. I'm sure she'll take the input into account and we'll of course have quite open discussion of the proposal when formulated. I'm not at all opposed to leveraging DHCP more fully (it was my primary job for 5+ years, after all), but we as always have to be pragmatic about where we put Sun's resources. Dave
