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 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. But I will nuke the getbootargs utility in favor of 'prtconf' output on sparc since that's really not needed :) > 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. > How is it envisioned to work for Sparc ? I understand LDOMs are out of scope > right now, but I assume they are to be considered later ? I don't now if enough thought has been put into the LDOM support for VMC to actually know how auto-shutdown might work in that case. > To tell the truth, I am not quite convinced about this solution, > as 'pkg image-create' might not be the first place where network > communication takes place - e.g. if manifest is to be obtained > from network. How is it guaranteed that things work correctly in > that case ? It won't work in that case or any case where there are intermittent connectivity problems. > 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. > However, I might recommend to put comment there explaining what > the purpose of implementing timeout for 'pkg image-create' is > and what the plans are as far as final solution is concerned. I will add generous comments in the transfer module to this effect. >> I'm ambivalent about making this change at this point but >> if you or others feel strongly, I could make the change. > > I think it might be better to let IPS layer take care > of this and tune its parameters to fit AI needs instead of > implementing another IPS timeout mechanism in AI. > Based on this, I am not suggesting to change other IPS commands > at this point, I am fine with RFE addressing this problem later > and maybe in different way. Okay, I will make a note of filing that RFE once this project integrates. Alok
