On 04/15/09 21:10, Dave Miner wrote:
> jan damborsky wrote:
>> On 04/15/09 18:21, Ethan Quach wrote:
>>>
>>> Putting aside our opinion of its usefulness for a bit, I think a part
>>> why we're here now is because this scenario is least worked properly
>>> for x86. When sparc came along, we didn't reevaluate whether it
>>> actually worked for sparc.
>>
>> I agree - in current implementation (based on how wanboot works and what
>> it allows), that scenario can't be accomplished for Sparc.
>>
>
> It's not really a useful scenario, as seldom is a user in a situation
> where they'll say "Hey, I don't care which of two different possible
> installations gets applied to a particular system". The useful
> scenario is one in which there is a default installation that's used
> for standard systems, and then there are other installation services
> which are used for specific exception systems. The latter are what
> you'd use create-client for; the former should just use the default
> service.
Agreed. This is the scenario which I think we implicitly assumed to
work before
8130 was reported. As you pointed out it defines two install service scopes
or bindings:
[1] per-client binding - explicitly established by 'create-client'
- max one per client, total number not limited
[2] 'default' - serving clients without per-client binding
- only one is active at a time
Right now, [1] works correctly for both x86 & Sparc.
When investigating 8130, I have realized that [2] doesn't seem to work
correctly neither for x86 nor for Sparc.
Sparc is more problematic, since if more than one install service is
created,
mismatch between boot archive and compressed archives appears. This is what
was initially assumed (when this discussion started) to be addressed by fix
for 8130.
When discussion was evolving, it seemed to appear that fixing 8130 in such
a way that [1]+[2] continues to work is problematic and risky at this point.
Then two approaches were suggested:
* support only [1] for Sparc
- it solves problem with mismatch, since mismatch only occurs for [2]
- it is not acceptable
* allow only one install service to be available at a time and
use it as default - which is [2]
- it seems to be too restrictive - only one install service for
all Sparc clients
- it doesn't solve mismatch problem
If my understanding is correct, now we are back in situation when
[1]+[2] is required to work ?
Let me try to verify if I understand what problems we are trying to solve
(and how) before I get completely lost :-)
[A] mismatch problem - tracked by bug 8130
------------------------------------------
affects only Sparc AI client when it uses [2]
Since it is caused by the fact that Sparc client obtains location
of AI image pieces from two places, I think the solution (at least
for now) would be to query one common source for obtaining
location for both boot archive as well as solaris*.zlib archives.
We can't do too much about boot archive stage at this point,
so let's take a look at the stage when solaris*.zlib archives
are obtained.
Since full path to boot archive is defined by 'root_file' option
in wanboot.conf file, if we have this info available in AI client,
I think it would help to solve the problem.
I was investigating what wanboot offers in this point and it seems
we can easily obtain particular wanboot.conf. During wanboot process,
wanboot.conf along with other files is bundled as HSFS filesystem
and provided by kernel as /devices/ramdisk-bootfs:a block device
(I finally realized what the wanbootfs file downloaded by client
can be used for :-).
Looking at how legacy installer makes it available, it is straightforward:
...
BOOTFS_DISK="/devices/ramdisk-bootfs:a"
if [ -b "$BOOTFS_DISK" ] ; then
mount -r -F hsfs "$BOOTFS_DISK" /etc/netboot > /dev/null 2>&1
...
Then we have wanboot.conf available in /etc/netboot/ directory in
microroot and we could determine location of solaris*.zlib archives
by inspecting 'root_file' option - it is created by installadm(1M)
in following format:
root_file=<ai_image>/boot/boot_archive
and solaris*.zlib archives are in
<ai_image>/solaris*.zlib
I haven't tried this yet, but it seems promising.
[B] correctly working [2] scope
-------------------------------
Assuming [A] is addressed, then [2] would work in following way:
x86 - first created service has 'default' scope
-----------------------------------------------
When local DHCP server is to be used, the first install service is
created along with -i -c options and IP pool is associated with
service-specific DHCP macro. Thus it is used as default, since
client loads menu.lst file defined in service-specific macro.
Any subsequent service (if created without -i -c) doesn't update IP pool
by calling pntadm(1M) leaving the first service used as 'default'.
Issues:
- It is a little bit problematic to change the default service
(e.g. delete old/create new), since appropriate IP pool has to be
updated with new dhcp service-specific macro. This is now only done
if '-i -c' options are provided and user has to know which IP pool
is to be updated.
- If default service is deleted, client is still served with menu.lst
file referring to it, as IP pool is still associated with service
specific DHCP macro.
- First one is always set as a default - this could be addressed by
explicitly specifying which one should be set by default (e.g.
by providing '-d' option as suggested).
Sparc - last created service has 'default' scope
------------------------------------------------
The reason is that each time new service is created,
/etc/netboot/wanboot.conf is updated. Specifying -i -c doesn't
affect this behavior, since DHCP server would be queried only for
network info (client IP, server IP, ...) and boot file (which is
wanboot-cgi common for all clients). Once [A] is fixed, 'RootPath'
option would be no longer utilized.
Issues:
- Last one is always set as default - this could be addressed by
explicitly specifying which one should be set by default (e.g.
by providing '-d' option as suggested).
I think we would need to clarify
* desired behavior for [2] along with corner cases and possible states
* what is appropriate/desirable to address for the current release
Thank you,
Jan
