I haven't yet received any help on this, but I've made some progress. After 
looking at how repsitory.db is built in Solaris:

    
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/svc/seed/Makefile

I added this to my ramdisk building process:

    ROOT=/home/mgoff/svn/ramdisk
    SVCCFG=$ROOT/usr/sbin/svccfg
    CONFIGD=$ROOT/lib/svc/bin/svc.configd
    DTD=$ROOT/usr/share/lib/xml/dtd/service_bundle.dtd.1
    MANIFEST=$ROOT/var/svc/manifest/application/honeycomb-net-filesystem.xml

    cd $ROOT
    REPOSITORY=$ROOT/etc/svc/repository.db
    SVCCFG_DTD=$DTD \
        SVCCFG_REPOSITORY=$REPOSITORY \
        SVCCFG_CONFIGD_PATH=$CONFIGD \
        SVCCFG_CHECKHASH=1 \
        PKG_INSTALL_ROOT=$ROOT \
        $SVCCFG import $MANIFEST

This results in my service running along filsystem/minimal at boot time, but 
the dependency is not enforced, which causes errors. The interesting thing is 
that the dependency is present in /etc/svc/repository.db:

NODE hcb101 ~ $ svccfg -s filesystem/minimal listprop                          
usr                                      dependency
usr/entities                             fmri     svc:/system/filesystem/usr
usr/grouping                             astring  require_all
usr/restart_on                           astring  none
usr/type                                 astring  service
devices                                  dependency
devices/entities                         fmri     svc:/system/device/local
devices/grouping                         astring  require_all
devices/restart_on                       astring  none
devices/type                             astring  service
honeycomb_filesystem_minimal             dependency
honeycomb_filesystem_minimal/entities    fmri     
svc:/application/honeycomb-net-filesystem
honeycomb_filesystem_minimal/external    boolean  true
honeycomb_filesystem_minimal/grouping    astring  require_all
honeycomb_filesystem_minimal/restart_on  astring  none
honeycomb_filesystem_minimal/type        astring  service
general                                  framework
general/entity_stability                 astring  Unstable
general/single_instance                  boolean  true
startd                                   framework
startd/duration                          astring  transient
start                                    method
start/exec                               astring  /lib/svc/method/fs-minimal
start/timeout_seconds                    count    0
start/type                               astring  method
stop                                     method
stop/exec                                astring  :true
stop/timeout_seconds                     count    0
stop/type                                astring  method
tm_common_name                           template
tm_common_name/C                         ustring  "minimal file system mounts"

and the service is running, but the dependency is NOT present in the runtime 
config:

NODE hcb101 ~ $ svcs -d filesystem/minimal
STATE          STIME    FMRI
online         12:20:43 svc:/system/filesystem/usr:default
online         12:20:48 svc:/system/device/local:default

NODE hcb101 ~ $ svcs -l filesystem/minimal                                     
fmri         svc:/system/filesystem/minimal:default
name         minimal file system mounts
enabled      true
state        maintenance
next_state   none
state_time   Mon Apr 23 12:20:49 2007
alt_logfile  /etc/svc/volatile/system-filesystem-minimal:default.log
restarter    svc:/system/svc/restarter:default
dependency   require_all/none svc:/system/filesystem/usr (online)
dependency   require_all/none svc:/system/device/local (online)

I would expect it to be in the runtime config since it's in the repository. 
What can I do to fix this discrepancy during ramdisk build time? I know how to 
fix it after booting from the ramdisk and the error has occurred, but the 
updates will not be saved to the ramdisk (part of our cluster node design), and 
therefore the changes have to be made during ramdisk build time.

thanks,
Mike
 
 
This message posted from opensolaris.org

Reply via email to