Re: 6.0.1 upgrade dhcp problem

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 6 Feb 2013 19:22:01 +1000
    From:        Ray Phillips <r.phillips%uq.edu.au@localhost>
    Message-ID:  <p05200f19cd37c4906ebd@[192.168.37.112]>

  | Yes, I've only seen sk0 configured properly once (maybe twice)

That it has ever happened is interesting, as it suggests non-deterministic
behaviour, which suggests that something weird is happening.

  | No, it's not.  By the way, the two DHCP servers are a failover pair 
  | running ISC's DHCP server version 4.2.5, but that's irrelevant to 
  | DHCP clients to the best of my knowledge.

That they're both the same version, suggests that Roy's thought that
the reason that one of them was ignored was because of a missing server-id
in the reply isn't correct.

I must admit, than when I say the ignored offer, I just jumped at the
conclusion that it was ignored because it arrived second, after the
other offer had arrived (but I have not looked at dhcpcd's source to
see if that is plausible) and ignored that as immaterial.  I didn't notice
that dhclient was picking the other offer.

  | Using dhcpcd's  --nohook mtu  option didn't help:

That suggests that it isn't the MTU setting that is causing a problem
(which is as I guessed, it just made no sense for it to be that) but
something else.    I'm still not convinced that it isn't related to
the spanning tree algorithm in some way, but I can't explain how that
would allow one system to work, but not the other.

  | # dhcpcd -U fxp0
  | #
  | 
  | So the -U option gave no output, even when I used it on the PC whose 
  | fxp0 NIC works (after configuring the NIC via sysinst's menu).

That is very odd, but could be explained because you're running this
with root on a cd, and so quite likely no writeable storage anywhere.
If you could mount a mfs or tmpfs on /var before starting the network
config (you may need to copy the real /var somewhere, mount a mfs,
then put the contents back to the mfs /var, so everything that should be
in /var remains there).   Or perhaps just mounting on /var/run would be
enough, I think that's where dhcpcd puts all its data - and that dir can
safely start out empty.

kre