Hi Karen, On 29/08/2011 19: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.
Interesting... and surprising that it would rely on fmd for that. > > 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. Yes, I would assume that it would be present in AI also, although the download phase may take along enough for fmd to be on-line before AI starts. > > 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. > > 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. Initially, I would tend toward Solution 1 for consistency - since for the installers to work correctly, they need to have a complete view of the system - if for any reason fmd would fail, then croinfo will also fail, resulting in the installers not getting a complete view of the system, and thus possibly making incorrect decisions, like the selection of disk to install to. What are the chances of fmd not starting successfully - I have no historical knowledge of this area, and it would be good to get input from people that do. If fmd is stable in this way, then proceed with Solution 1 - I'm not sure that speed of startup is important for an install - much more important I would feel is for things to be successful. If it's acceptable for fmd to enter maintenance or be disabled, then we cannot rely upon it to be always there, and as such would need to go with Solution 2. Thanks, Darren. > > 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
