hi Stephen
> I'm not sure about your upgrade assertion. Upgrade is running, in the > miniroot, the version of the system that will be installed. Live > Upgrade is potentially running a previous release, but the new BE > isn't executing so routeadm(1M) wouldn't be invoked there. > > Why can't your packaging handle the append using the > preinstall/postinstall mechanism used in the other ON packages? > > > as i understand it, routeadm is invoked by users in their "finish" custom jumpstart scripts in order to customize the routing options for the system. as such, the information about what that customization would be wouldn't be available at the time the relevant SUNWcsr package is installed. in the past, this simply involved changing values in <alternate-root>/etc/inet/routing.conf. however, the problem here is that in it's (proposed) new form, routeadm allows customization of routing services by enabling/disabling/modifying smf properties (see: https://www.opensolaris.org/os/community/networking/quagga-design.pdf for design details and draft manpage). my concern is that these new commands would fail during upgrade when the "finish" jumpstart script is run, so i'd like routeadm itself to detect this condition and drop the commands in the upgrade script, to be run on first reboot post-upgrade, when SMF is available again. >> (by the way, i assume a good test for SMF >> availability is calling scf_handle_create(), getting a failure with >> SCF_ERROR_NO_SERVER set as errorcode?) thanks for your help! >> > > > Well, it depends on how you intend the linking of libscf.so to be > handled. If you've managed that, then such a call might be > appropriate. An easier test might be the presence of > /etc/svc/volatile/repository_door. > > > great, thanks! this is a much better test. alan This message posted from opensolaris.org
