Subject: Re: dhclient support..
To: None <>
From: Robert Elz <kre@munnari.OZ.AU>
List: current-users
Date: 10/28/1998 11:38:42
    Date:        Tue, 27 Oct 1998 11:57:12 -0500
    From:        Bill Sommerfeld <>
    Message-ID:  <>

  | Yes.  Ideally an enhancement request, with diffs included.. :-)

If no-one else does, and it is desired, I can send in my diffs.

I have a lab of identically configured IPX's (literally identical, aside
from the NVRAM) which all boot just fine (including obtaining their names
from the dhcp server).

I haven't bothered with syslog - I see that as a different issue.  Ideally
syslogd ought to be one of the first processes started after boot (and fsck),
so that all kinds of startup stuff can be logged.   That dhclient syslogs
get missed is no worse than missing any of the other messages that are
written to the console during boot and lost after that.  dhclient does write
sufficient info to the console for any problems to be detected (if you can't
get to the console, and dhclient fails, then you're not going to be getting at
the syslog files either, in fact, typically, you won't finish booting until
dhclient has succeeded).   For getting historical info about what dhclient
actually achieved, after it has worked, the leases file is better value tham
the info in syslog, so the missing syslog is a very minor annoyance, at most.

My changes as written now do assume an "all or nothing" approach to dhcp
configs - while I allow you to specify which interfaces should be queried
(or simply all of them), any that dhclient doesn't configure (if it is
enabled) aren't configured at all.    I suppose that should be fixed, perhaps.

For the mount stuff, what I do is to the "critical filesystems" mount loop
twice, the first time mounting only filesystems that are mounted form /dev/
something or other.   That gets all of the "local" important filesystems
(which has to be enough for dhclient to use, fairly obviously).   Then
netstart is run, which gets the network running, etc, and after that,
the critical filesystems loop is run again, omitting anything that is already
mounted, and not restricted to local filesystems.    That allows /usr to be
NFS mounted after dhclient has found an address, if that's your bag.

I also use this (more recently) in a 386 laptop, it all works fine there as
well.   Lastly, the IPX's were running 1.3.2 when this was originally done,
their kernel has been upgraded to 1.3H (without UVM, not that that will matter)
and, as you'd expect, nothing broke in this area.