Karen,
Just to be sure, does croinfo also depend on devchassisd? If so, I'm
wondering if the relevant service here should be
svc:/system/devchassis:daemon (or perhaps both to be clear.)
On 08/29/11 11:54, Karen Tung wrote:
I am trying to figure out what's the best way to fix bug 7083584:
7083584 snv 172 text installer does not initially present SAS drive
aliases/receptacles
http://monaco.sfbay.sun.com/detail.jsf?cr=7083584
Receptacle information is not displayed the first time text installer
is run because fmd SMF service is not online yet, and croinfo command
replies in fmd to get the information.
To confirm that the bug exists because fmd service is not yet online,
I built a special ISO where I make the install-setup SMF service dependent
on fmd SMF service, and the bug submitter confirmed that problem is gone.
Even though this problem is reported on the text installer,
it could also exist for the other installer images, since there's
no explicitly dependency to make sure that the installers
are not run until fmd is up.
I can think of 2 ways to fix the problem, both have it's advantages
and disadvantages. I would like to hear your opinion on which way
is better.
Solution 1
--------------
Make install-setup SMF service(used by text installer) and
manifest-locator SMF service(used by AI) dependent on fmd SMF service.
There's no SMF service that starts the GUI installer, but since it
takes so much longer to start X server, GNOME, auto-login..etc..
By the time the GUI installer starts, fmd will very likely be online
already.
The advantage of this approach is that we just let SMF take care of
the dependencies. The disadvantage is that if fmd failed to start
for some reason, the installers will fail to start too. Furthermore,
if fmd takes a long time to start, the installers will appear to take
a long time to start. I booted the text installer image I built with
fmd dependency on my laptop. I don't notice any difference in
start up time. I am not sure whether fmd will take much longer
to start on machines with SAS drives.
To me, it would seem like any frailty or expediency issues are really
just issues in those services and would ultimately need to be addressed
there. Solution 2 seems like it's preemptively working around this.
-ethan
Solution 2
---------------
Add code in target discovery to check the status of fmd SMF
service. Right before we need to run the croinfo command, we check
for the status of the fmd service. It's it's not yet online, we wait a
specified period of time. If it is still not online by the time we
finish waiting,
we will log a message in the installer log indicating the problem, and
proceed
with running croinfo to retrieve the information...etc..
The advantage of this approach is that even if fmd SMF service fail for
some reason, people can still use the installers as usual. Also, there's
no potential start up delays. The disadvantage is that we need to have
special code in our gate to handle SMF status.
I prefer solution 2, Drew prefers solution 1.
We would like to hear your thoughts.
Thanks,
--Karen
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
