Hi Tony, Yes, svcadm refresh for filesystem/minimal is needed, and will work to make the dependencies active at runtime. However, changes made to the ramdisk at runtime will not persist across reboots (which is by design so that our cluster node images do not diverge over time). Therefore we need to make all necessary changes during the ramdisk build process.
I'm about to try Liane's suggestion of building the repository myself, so that the dependencies are set from the beginning and a refresh is not necessary. thanks, Mike Tony Nguyen wrote: > Michael, > > Not familiar with the ramdisk build process, so I may be totally off > here. Is svcadm refresh/restart for filesystem/minimal needed? How do > you fix it after the boot? > > Manifest-import depends on filesystem/minimal so adding the new manifest > and wait for manifest-import wouldn't work. > > -tony > > Michael Goff wrote: >> 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 >> _______________________________________________ >> smf-discuss mailing list >> smf-discuss at opensolaris.org >> >
