Karen,
-------------------------------------------------------------------------------
usr/src/cmd/distro_const/checkpoints/pre_pkg_img_mod.py
-------------------------------------------------------------------------------
- line 166. We can not call the repository "/tmp/install-repo.db".
This will cause problem more than 1 DC build happens
simultaneously on the same machine. This will happen
on public build machines
Oh hey. Good point. I'd really like to keep the construction of the
repo in /tmp, however. How would you feel if we attached the process
PID to the filename? To ensure the file is completely gone by the end
of the configure_smf() method, I can put an explicit check via
os.path.exists().
The speed gain by moving to /tmp is quite substantial. I go from 5+
minutes to ~ 20 seconds when I move it out of the dataset.
- lines 180-186: Would this be a good time to change to using the
solaris_install.Popen()?
That way, you can just pass in the logger, and the code can be simplified.
I really don't want to do that conversion to DC right now. I will
happily file a bug on it with the intent to fix it "soon" (along with
creating a functools.partial object for Popen), but that's a massive
undertaking.
- lines 227-231: instead of hard coding the values here, why not get
all the
keys from "smf_env_vars", and unset them so you don't need to worry about
missing anything or keeping the list up-to-date in the future.
I can do that.
Other files in the webrev look OK to me.
I've tested full installs (from DC -> install -> reboot) with both
stock 167 bits from ipkg.us.oracle.com and SMF project nightly bits.
Everything checks out with no issues.
You only mention DC->install->reboot, and didn't mention about
observing that all the SMF services are registered
without errors, and the specified user and role are created as
expected..etc.. I assume that's all done as well,
and there's no problem.
The resulting virtualbox guest came up with no SMF warnings or errors
aside from ones typical to b167. I can't remember off-hand which
service had an issue but I'll redo the install tomorrow morning and
comment with a screenshot if you'd like.
I see that you also changed the InitializeSMFZone class in
initialize_smf.py. Perhaps you need to do a zone install to
make sure that the change doesn't cause any problem?
I will get a zone install done as well to confirm the fix.
Thanks for the review, Karen!
-Drew
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
