"J. Seth Henry" <jshamlet at comcast.net> writes:
> Ok, I think I just qualified for an idiot award. After a little more
> poking around, I discovered that it was the read-only filesystem that was
> causing the problem. I rebuilt the microdrive image, and included a
> special /dev this time - which I mount over the original /dev. Now, I
> don't seem to be having any problems with sshd.
>> Unfortunately, I appear to have made my dhclient problem worse. Now, it
> hangs, producing volumes of log data like this:
>> Apr 3 17:52:45 dhclient: New IP Address (aue0): 192.168.1.5
> Apr 3 17:52:45 dhclient: New Subnet Mask (aue0): 255.255.255.0
> Apr 3 17:52:45 dhclient: New Broadcast Address (aue0): 192.168.1.255
> Apr 3 17:52:45 dhclient: New Routers: 192.168.1.254
> Apr 3 17:52:45 dhclient: New Network Number: 192.168.1.0
> Apr 3 17:52:45 dhclient: New Broadcast Address: 192.168.1.255
> Apr 3 17:52:45 dhclient: New IP Address (aue0): 192.168.1.5
> Apr 3 17:52:45 dhclient: New Subnet Mask (aue0): 255.255.255.0
> Apr 3 17:52:45 dhclient: New Broadcast Address (aue0): 192.168.1.255
> Apr 3 17:52:45 dhclient: New Routers: 192.168.1.254
>> I have to hit CTRL-C to get a login...
>> I tried running dhclient under truss, but it gives me a segmentation fault
> before getting very far. It doesn't seem to be attempting to write to
> files on a read-only filesystem though. I can post the output of truss if
> anyone is interested.
>
I don't remember the history of this thread, but my first thought
would be that it's probably trying to update /etc/resolv.conf and/or
/var/db/dhclient.leases
I don't think a failure to update resolv.conf would result in
this behaviour. But for dhclient.leases, it might.
Advance warning: if you're using ntp, you will have a similar
issue for ntp.drift.
--
Dan Pelleg