* Alan Maguire <alan.maguire at sun.com> [2005-12-02 01:47]: > hi folks > > quick question - i'm working on service conversions for the Solaris > routing services (in.routed, in.ripngd), and on enhancing routeadm > (1M), the routing management tool, to support listing, > enabling/disabling, modifying properties of these services a la > inetadm. > > one problem with this is that these operations would fail during > upgrade when SMF is unavailable. given that routeadm is often used in > jumpstart scripts, the solution i'd like to adopt is for routeadm to > assume upgrade on detecting SMF unavailability in conjunction with an > alternate root having been set (routeadm supports setting an alternate > root via chroot). if this is the case, the SMF commands are appended > to <alternate_root>/var/svc/profile/upgrade.
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? > does this solution seem ok? (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. - Stephen -- Stephen Hahn, PhD Solaris Kernel Development, Sun Microsystems stephen.hahn at sun.com http://blogs.sun.com/sch/