> To question two points not quoted: > 1) I'm a bit surprised you're using a dependent, rather than a > dependency. Are network/physical and datalink-management really > separable components of the system?
My understanding from Cathy is that she did it this way to simplify backwards-BFU, since the "dependency" approach ended up with dangling dependencies. But that BFU problem may just be another symptom of this issue. Given that according to svccfg the dependency information already seemed to be correct prior to reboot though, it seems unlikely that this is responsible for the issue though, right? > 2) The duplicate dependencies in the svcs -d output are a bit worrisome. > I haven't seen that bug before. Alan sent me email offline that explained this: svcs -d is matching two service instances (network/physical:default and network/physical:nwam) that have identical dependencies, hence the apparently-duplicate output. So I think that's not a bug after all. > Honestly the best thing that I'm coming up with at this particular > moment (given the urgent nature) is for us to give you a call to > specifically rotate the snapshot before reboot. (Or, at least to remove > the running snapshot so we automatically fall back.) Our target integration date (which aside from this issue is on-track) is in two weeks; can something be cons'd up in that timeframe? Seems pretty tight. > You could test that this will work by explicitly deleting > network/physical and re-importing it (with SVCCFG_REPOSITORY set). Sure, I will try that. -- meem
