Hi Alok,
Alok Aggarwal wrote: > Hi Jan, > > On Thu, 17 Sep 2009, Jan Damborsky wrote: > >>> I actually can't get devprop(1M) to give me any output >>> on sparc or x86, I'll play with it some more since it >>> seems much cleaner. >> >> It seems to work correctly for me on x86 - e.g. >> >> $ prtconf -vp | grep boot >> bios-boot-device: '80' >> >> $ devprop bios-boot-device >> 80 >> >> But it doesn't seem to work on Sparc: >> >> # prtconf -vp | grep bootargs >> bootargs: 00 >> # devprop bootargs >> >> # >> >> It seems like a bug, since man page doesn't mention that >> devprop(1M) is supposed to work only on some platforms. > > I played around some more with devprop(1M). It doesn't > work on the couple of sparc systems I tried it on. > > So I've filed (will take sometime to show up on bugs.opensolaris.org) - > > 6883221 devprop(1M) does not work on sparc systems Thank you for filing the bug. > > Regarding replacing the use of 'prtconf' out vs. devprop(1M), > I think I am going to defer that to the following bug fix > to tackle - > > http://defect.opensolaris.org/bz/show_bug.cgi?id=11244 > 11244 - devprop(1M) could be used to obtain x86 install options > instead of > parsing prtconf(1M) output > > given that it seems to work on some machines but not others. ok. > > But I will nuke the getbootargs utility in favor of > 'prtconf' output on sparc since that's really not > needed :) That sounds good :-) > >> Understood. Even if we don't want to deal with decomposing the >> solaris.zlib, >> I can still see the solution. If my understanding is correct, we can >> specify >> manifest location in GRUB ('aimanifest' option is being introduced). >> Since VMC is going to decompose the image anyway to enable shutdown >> in GRUB >> menu, it could change 'aimanifest' instead to point to VMC manifest >> which would >> be already part of the image - it might look like default with shutdown >> enabled. I am actually not proposing to do any real changes at this >> point, just >> trying to understand the problem :-) > > So, for this phase of VMC, they didn't want to go > through the extra work of decomposing the zlib > archives (they currently decompose the top level of > the iso to modify GRUB only); and, also modifying > the AI manifest. > > I would expect that once VMC gains the ability to > let the user specify an AI manifest location to > install the VM, we'd introduce "auto-shutdown" as > part of the AI manifest. At that point, we'd really > like to do away with this auto-shutdown flag on the > GRUB line. ok. >> I think the better approach would be to wait until network >> is brought up. It seems nwam team might provide some advice >> what and how to check for network state we are interested in - >> we could pick up one from list of states they defined: >> http://www.opensolaris.org/os/project/nwam/architecture/#state-machine >> >> But since both are just interim solutions until nwam team delivers >> stable >> API we could consume, I am fine with not changing the code at this >> point. > > I agree that really the correct approach here is to > use nwam profiles. > > I investigated the use of nwam profiles in this case but this > functionality is changing with NWAM Phase 1. Once NWAM Phase 1 > delivers, I think we need to take another look at how that > can be leveraged to make AI more resilient to network failures/ > interruptions. ok. Thank you for clarifying those points, Jan
