Hi, Cathy Zhou wrote: > Hi Dan/Team, > > I tried to test bfu from snv_74 to the clearview-uv bits today with the > following configuration: > > a. aggr1 created over bge1 > b. /etc/hostname.aggr1 > > The system successfully booted but it fails to plumb the aggr1 > interface. The problem is that the data-link configuration migration > (aggregation creation in this case) happens in the > /var/svc/profile/upgrade script, which is run by the > system/manifest-import service, and is after the network/physical > service (which plumbs the aggr1 interface). > > I am wondering while you tested system upgrade, whether the same problem > showed up. >
I did not see the same problem, but I think that might be because I did not test the same way you tested. I created a set of aggregations using bge[1-3]. I'd have one over bge1, and another over bge2 and bge3. Once I created the aggregation, I'd make sure the configuration in /etc/aggregation.conf (or /etc/dladm/aggregation.conf, depending on the OS version) was correct, and then I'd upgrade the sytem to my test bits. After the system rebooted, I'd check two things: - the contents of /etc/dladm/datalink.conf had the correct information for both aggregations - that dladm show-aggr showed the correct information for both aggregations. If both were correct, I considered that the test passed and I went on to the next OS version. I didn't try any tests involving /etc/hostname.aggrN, that was an oversight on my part. Sorry. > I can think of two options to solve this problem: > > 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. > > 2. Change the dependency so that instead of system/manifest-import > depending on network/physical, we make network/physical depends on > system/manifest-import. > > Option 2 requires to break the current dependency between > manifest-import and network/physical. I don't know it is possible. > Today, system/manifest-import indirectly depends on > network/iscsi_initiator and system/identity:node, which both depends on > network/physical. > I think Seb's option three is the best way to go. Dan
