Karen Tung wrote:
> Hi Jack,
> 
> Thank you for your comments.  See my responses below.
> 
> Jack Schwartz wrote:
>>> Even though "title" sounds very general, the fact that it is
>>> within the <grub_menu_modification> block means that it
>>> is only applicable to grub_menu_modifications.
>> There are currently three entries (excluding the hard disk entry) 
>> which appear in menu.lst when the <grub_menu_modification> section is 
>> blank or missing.  These are:
>>
>> OpenSolaris 2009.06 snv_xxx X86
>> OpenSolaris 2009.06 snv_xxx X86 VESA driver
>> OpenSolaris 2009.06 snv_xxx X86 text console
>>
>> Are you suggesting to exclude these from the new title?  I think that 
>> would be a mistake.  The title should affect all entries (except hard 
>> disk) whether placed in menu.lst automatically or specified by the 
>> manifest.
> Those will certainly not be excluded from the new title.  Every entry in 
> the grub menu will have the new title, if specified.
> What I meant is that I think using the <title> shouldn't cause any 
> confusion since it is within the <grub_menu_modification>,
> so, that would only apply to grub menu entries, and it is not a "title" 
> for anything else in the image.
>>> 2) Another problem to solve is how to pass this special string into
>>> the grub menu of the installed system.  I was planning to parse out 
>>> the special string from the Live CD's
>>> menu.lst.  However, I realized that there are many
>>> entries in the Live CD's menu.lst and many of them have suffix.
>>> So, which one should I use as the title.
>>>
>>> At this time, the DC creates the Live CD's grub menu entries
>>> and I know for a fact that the first entry does not have the suffixes.
>>> I remember discussion about future improvement and the possibility of
>>> moving the accessibility entries to the top or something.
>>> So, perhaps it is not a good idea for me to rely on the order of
>>> the Live CD's grub menu entries.
>>>
>>> To solve this problem, I propose putting the special string for
>>> the grub menu(if any) into the .image_info file on the Live CD.
>>> This entry to .image_info will only be added if there's a special title.
>>> The ICT can look up the info from the .image_info and modify the
>>> entries in menu.lst as needed.  This won't rely on the ordering of
>>> the grub menu entries, and avoids all the parsing of Live CD's menu.lst.
>>> Your thoughts?
>> DC (grub_setup.py specifically) already gets the "base" title from 
>> /etc/release, so you already have it at your disposal.  I would 
>> imagine that the proposed changes would be implemented in this same 
>> file, which would make it really convenient for you.  If the manifest 
>> had something specified for the title, it could override the 
>> /etc/release value.  This should handle it for liveCD.
> Agreed.  Like you said, it is easy to determine whether the installed 
> system's grub menu needs to be updated by
> comparing /etc/release with the LiveCD's grub menu.  The harder problem 
> is what's the best way to
> pass in the special string.
> 
>> I'm not sure what ICT does at hard-disk install time, but by the time 
>> it would run, it could just interrogate the liveCD's menu.lst for the 
>> release string.  If you are worried about which menu.lst string it 
>> would parse, then how about adding a commented, keyed line in menu.lst 
>> which would have a magic string ICT can look for, followed by the 
>> release string it should use.
> ICT uses bootadm to generate the installed system's grub menu.  Whatever 
> that's on the liveCD's menu.lst is ignored.
> bootadm takes the title from /etc/release.  So, we want to be able to 
> retrieve the special title string somehow.
> My suggestion was to store it in .image_info, since that's where 
> everything about the live CD image should be stored.
> Your suggestion is to store it as a comment in the live CD's menu.lst.  
> Both approach would work.
> For me, I think it is easier to retrieve it from the .image_info.
> 
> Anybody else have an opinion on this?
> 

I would put it in the .image_info file.

Dave

Reply via email to