Alok Aggarwal wrote: > > On Tue, 22 Sep 2009, Ethan Quach wrote: > >>>> usr/src/cmd/auto-install/svc/manifest-locator >>>> --------------------------------------------- >>>> 78-82, 102-104 - This should be done in get_manifest itself. >>> >>> I don't think get_manifest should make the assumption >>> that it can get called just on the console. >> >> That's fair enough then. Though I have a couple of >> additional questions then ... >> >> 1) >> TERM=sun-color >> export TERM >> >> Does this work properly for all cases, even when a user >> is tipped in via serial line? > > Yep, it does. > >> 2) >> exec </dev/console >/dev/console 2>&1 >> >> Is this a workaround for some known issue? If so, do you >> know what? > > I don't actually know if this a workaround for something > but it is needed for prompts to be displayed on the > console. > > I did try your suggestion of specifying the "need_session" > property in the SMF manifest as a way of indicating that > the manifest-locator service can have controlling access > to the console but it doesn't work. I still don't see > the prompts on the console. > > So, I think I'm going to stick to what I have for now.
Okay. Thanks for trying that. > >>> In this >>> specific case, the caller knows that it will be called in a >>> certain scenario so it seems that the caller should do >>> the appropriate setup prior to calling get_manifest. >>> >>>> 57-60 - Can we loop and process instead of processing a set >>>> number of args? >>> >>> Sure, I can look into that. > > I actually ended up not implementing this change because > I didn't see the benefit of doing so given the use of > a single 'prtconf -vp' call to get bootargs; and, us > needing to reference only two of the arguments. > > If at some point there's value in processing all of the > args, this can be extended pretty easily. Ok > >>>> usr/src/cmd/slim-install/svc/live-root-fs-minimal.xml >>>> ----------------------------------------------------- >>>> 87 - Is there any other way of making this determination >>>> for x86? >>> >>> I don't think so, our code uses the same check all over >>> the place. >> >> The code is in other places, but it seems this is the first >> place we're using it to determine whether or not we're booted >> from media or from net. >> >> My concern is that we're using an implementation detail to >> imply meaning of something that's not necessarily related. >> >> What happens if a user edited the grub menu entry when >> booted to AI bootable media and added 'install_media' ? >> (I think we want this case to actually work eventually, >> to support users who need to use the bootable media as a >> boot-shim to get around DHCP or other network limitations.) >> >> If parsing the boot args is our only means of differentiating >> right now, could we just define a new boot arg to determine >> this explicitly? e.g. media_boot=true or something? > > Okay, I'm bought into this and I've made the code changes > to support media_boot=true. > > I am still uncomfortable with the way we make this determination > on sparc (check for the existence of a certain device) however. > But I can't think of a better way of doing it either. The existence of that device isn't user changeable upon the boot at least. But I agree, we need a better way of determining this for Sparc. Did you take a look at using netbootinfo? thanks, -ethan > > Alok
