http://defect.opensolaris.org/bz/show_bug.cgi?id=9947
Summary: NWAM causes network disruption when BFUing over NFS -
hanging BFU
Classification: Development
Product: nwam
Version: unspecified
Platform: ANY/Generic
OS/Version: All
Status: NEW
Severity: minor
Priority: P3
Component: ON misc
AssignedTo: nwam-dev at opensolaris.org
ReportedBy: John.Leser at sun.com
QAContact: nwam-dev at opensolaris.org
I've been noticing a problem with BFUing my system with NWAM enabled.
basically, BFU goes fine for a while, copies over all the files, then:
...
For each file in conflict, your version has been restored.
The new versions are under /bfu.conflicts.
MAKE SURE YOU RESOLVE ALL CONFLICTS BEFORE REBOOTING.
To install resolved changes required for reboot in the boot
archive, invoke 'bootadm update-archive'
Removing obsolete smf services ...
Disabling unneeded inetd.conf entries ...
Connecting platform and name service profiles ...
Marking converted services as enabled ...
* At this point, it hangs forever.
At this point, I can CTRL-C out of the BFU shell, and I find that I only have
loopback interfaces enabled. I think at some point, BFU is stopping NWAM,
which brings down my interface, which cuts off access to
/net/elpaso.eng/opt/onbld, which will cause commands to hang since that's where
I get BFU (and most people will get BFU over a network path, I would think, so
as to always be using an up-to-date version). It's somewhat problematic that
this happens before BFU conflicts are resolved.
Maybe we need to modify BFU to leave the nwam service alone?
The obvious workaround has been to disable NWAM and switch back to a manual
network configuration while BFUing, but it would be better not to force this on
everyone wishing to BFU.
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
