Hi Jan,

I filed these bugs:
#6436: SC manifest needs more criterias to match sysidcfg functionality
#6437: SC manifest criteria to customize menu.lst in installed system

Thanks,
David

jan damborsky wrote:
> Hi David,
>
>
> David Garcia - ONPIT wrote:
>   
>> Hi Jan,
>>
>> I agree with that. Adding such options in the SC manifest would be 
>> better. Something like:
>> <propval name='boot-options' type='astring' 
>> value='console=ttya,enable_ssh=true' />
>>
>> Also maybe it would be interesting to add an option to change the 
>> default boot entry? (i.e. it's commonly needed to change the default 
>> boot in network environments where the splashimage interfeeres with 
>> the tip lines)
>> <propval name='boot-default' type='integer' value='1' />
>>     
>
> those suggestions are definitely good food for thought :-)
> Could you please file bug and capture them, so that we
> are aware of this need ?
>
> Thank you very much !
> Jan
>
>   
>> Thanks,
>> David
>>
>> jan damborsky wrote:
>>     
>>> Hi David,
>>>
>>>
>>> David Garcia - ONPIT wrote:
>>>       
>>>> Hi Sue and Jan,
>>>>
>>>> As this is currently coded, the string after '-b' will be concated 
>>>> to the default root entry in menu.lst, so I think it would make more 
>>>> sense if the description in the man page changed to something like:
>>>>
>>>>   -b boot-options
>>>>   Optional: Add additional boot options in the form
>>>>   <property>=<value> in the client-specific
>>>>   menu.lst file in /tftpboot.  Use  this option to set
>>>>   boot properties that are specific to this client.
>>>>  
>>>> This is because with the previous description it looks like we can 
>>>> only set one property when we actually can set several.
>>>>
>>>>
>>>> Other than that, would it make sense to propagate those changes to 
>>>> /rpool/boot/grub/menu.lst in the client at post-install time?
>>>>         
>>> I think they should be applied only during process of installation.
>>> The reason is that they might be installation specific and not
>>> applicable to the installed system.
>>> (enabling remote access for observing install process, turning on 
>>> debug mode, ...)
>>>
>>> My feeling is, that all customization specific to the installed image
>>> should come from AI System Configuration manifest.
>>>
>>> Thank you,
>>> Jan
>>>
>>>       
>>>> Thanks,
>>>> David
>>>>
>>>> jan damborsky wrote:
>>>>         
>>>>> Hi Sue,
>>>>>
>>>>> the fix looks good to me.
>>>>>
>>>>> I have some generic comments. If they might
>>>>> be valid, we could just file new bugs for
>>>>> tracking them.
>>>>>
>>>>> Looking at installadm(1M) man page, it looks
>>>>> like only one name-value pair can be specified
>>>>> by -b option. Is this the case or could I specify
>>>>> more than one property ?
>>>>>
>>>>> It seems that this feature is currently only
>>>>> implemented for x86 platform. I think we will need
>>>>> this also for Sparc.
>>>>> For example, if I would like to enable ssh in AI
>>>>> environment along with turning on debug mode,
>>>>> I might just specify something like
>>>>> "-b enable_ssh=true,install_debug=true" when configuring
>>>>> particular client.
>>>>> Do you think that taking advantage of '-b' for such
>>>>> kind of things is the right approach or another
>>>>> mechanism should be developed for passing user
>>>>> arguments to AI client ?
>>>>>
>>>>> Thank you,
>>>>> Jan
>>>>>
>>>>>
>>>>> Sue Sohn wrote:
>>>>>  
>>>>>           
>>>>>> Please review the changes for:
>>>>>>
>>>>>> 6388 create-client -b option should be supported
>>>>>> http://defect.opensolaris.org/bz/show_bug.cgi?id=6388
>>>>>>
>>>>>> which are posted at:
>>>>>>
>>>>>> http://cr.opensolaris.org/~sohn/6388
>>>>>>
>>>>>> Thanks,
>>>>>> Sue
>>>>>> _______________________________________________
>>>>>> caiman-discuss mailing list
>>>>>> caiman-discuss at opensolaris.org
>>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>>>>     
>>>>>>             
>>>>> _______________________________________________
>>>>> caiman-discuss mailing list
>>>>> caiman-discuss at opensolaris.org
>>>>> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>>>>>   
>>>>>           
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
>   


Reply via email to