* Nirmal Agarwal ([email protected]) wrote: > Hi Glenn > On 7/8/2011 11:07 PM, Glenn Lagasse wrote: > >Hi Ronan, > > > >* Ronan O'Connor ([email protected]) wrote: > >>To ask the question in a slightly different way: > >> > >>What would the steps be to restart an install from the console of a > >>system which had failed to complete AI? > >> > >>For instance, recently we've had a network outage in the lab which > >>caused an AI to timeout and fail. Having logged onto the system and > >>diagnosing the error, it would be more sysadmin friendly to kick of > >>the auto install process from the miniroot, rather than having to > >>possibly re-setup AI and reboot system etc. > >I would *guess* (which means I haven't tried this, and I'm quite > >probably incorrect) that you could zpool destroy the root pool that AI > >created for the install and then restart the auto-installer. > > > I tried this but it fails since one of the zfs device was assigned > as dump device. Then I have to assign some other device as dump > device and then destroy the zpool.
Yeah, I'd forgotten about that particular bit. I would have thought you could just delete the configured dump device and then destroy, but it's been a very long time since I've touched AI or an AI install. > But I am still not able to understand the difference between a > reboot of the client and restarting the service since both results > in zpool destroy. I'm not sure what you mean here. If you reboot the client, then when AI starts up it's going to think this is a fresh install (and nothing will be setup, like for instance the dump device). Restarting the service after a failed install (without rebooting) as you've seen can leave things in an odd state such that it doesn't look like a fresh install to AI. In the case you had, the install aborted abnormally so even if there is cleanup code in AI (and I'm not saying there is because honestly I don't know) it wouldn't have run and so just restarting the service doesn't 'clear' anything up. > The log file /system/volatile/install_log will not be affected by > removing the pool. No it won't, but potential forensic evidence *on/in* the pool could/would be. I'm just hypothesizing here since I didn't write AI but making an administrator explicitly recover from a failed install (like the one you have, which means you would have to explicitly destroy the root pool that AI created) puts the burden on you the administrator and I would think that the expectation is if you know enough to fix things up, you've figured out what went wrong or why or been in touch with people before doing so. And if you haven't then you'd have no one to blame but yourself if you just went ahead and destroyed potentially useful data that support might need/ask for in order to diagnose/reproduce the issue you ran in to. I'm not saying that this is the real reason things are the way they are, but it's my interpretation. It could also easily not be intended to behave this way and I'm just wrong :-) Bottom line: Take everything I've said with a grain of salt. I haven't used AI in over a year. I was trying to provide you with a way to get up and running. If you need more concrete answers, you'll need to get them from someone much more familiar with AI's internals/design/expected behaviour than I am. Cheers, -- Glenn _______________________________________________ caiman-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
