From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5da819aa6015a554830612e0ff392ecd@plan9.bell-labs.com> From: "Russ Cox" To: 9fans@cse.psu.edu Subject: Re: [9fans] dhcpd and other CPU server fun. In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Mon, 21 Apr 2003 10:29:34 -0400 Topicbox-Message-UUID: 93bf4b74-eacb-11e9-9e20-41e7f4b1d025 > Finally, sometimes when the CPU server comes up, it has the right IP > address, and you can even cpu -h to it by its right hostname, but ndb/cs > has set the wrong sysname in /dev/sysname. Again, this is pretty random. > From one boot to the next it happens or it doesn't. Any idea why this > would happen? This fits with your other DHCP problems, which presotto answered. If the rogue non-Plan 9 DHCP server answered, it might give out the wrong sysname. I'm not sure how to turn off the VMware DHCP server, but I bet it's in the documentation. Ndb/cs sets the sysname using, in order: an environment variable $sysname the contents of /net/ndb (set during dhcp) the current ip address, looked up in the network db the current ether address, looked up in the network db > The other thing I'm seeing is that the CPU server will get completely hung > on the way up. The CPU server and auth server send packets out to each > other, to no avail. Is this (I'm guessing) a VMWare thing, or is there > something else going on? Anyone else seen this either with vmware or real > hardware? I've had no such problems with VMware, but it's been a while since I did a boot over a virtual network. Which network mode are you using? Are they on the same virtual network? Which packets are they sending to no avail? Russ