David Bustos wrote: > Quoth Sebastien Roy on Wed, Oct 10, 2007 at 06:48:02 -0400: >> Cathy Zhou wrote: >>> 1. Instead of write those "dladm" commands to /var/svc/profile/upgrade, we >>> write it to another script, and run that script at the very beginning of >>> network/physical service. > > That should work, I think.
The downside of this one, however, is you now have this upgrade turd in the network/physical method script that is run forever. >>> 2. Change the dependency so that instead of system/manifest-import >>> depending >>> on network/physical, we make network/physical depends on >>> system/manifest-import. >> Another potential option: >> >> 3. Create a dlmgmt-upgrade service which disables itself the first time >> it is run. This service would read the dladm command from the custom >> script described in 1. The inetd-upgrade service is similar to this. > > I doubt this will work since presumably dlmgmt-upgrade would be > installed by droping a manifest into /var/svc/manifest. In that case > the service won't be created until manifest-import anyway. > > You could pre-import dlmgmt-upgrade's manifest into the target > repository with SVCCFG_REPOSITORY. That's private and in theory can > break at any time, though. I'm not sure I understand. There has to be a way to introduce a new service to SMF which can exist anywhere in the dependency tree. Otherwise, two reboots would be required after having upgraded a system to a version of Solaris containing such a service. From what I read above, I'm gathering that because manifest-import starts after network-physical, that we can't introduce a new service which needs to start before network-physical? I'm confused. -Seb
