How to not break nfsroot

Ferenc Wagner wferi at niif.hu
Wed Apr 28 13:02:15 UTC 2010


Glenn Satchell <glenn.satchell at uniq.com.au> writes:

> I don't have any direct experience with nfsroot/dhcp but I think that
> you will need to make some changes to dhclient-script. [...]  There is
> a mechanism where you can override actions using dhclient-enter-hooks.

Hi,

Thanks for hinting at exit_with_hooks, I didn't know about it.  The
documentation says:

  If an error occurs during the execution of the script, it can set the
  exit_status variable to a nonzero value, and /sbin/dhclient-script will
  exit with that error code immediately after the client script exits.

But this doesn't seem to hold, setting exit_status is not enough in
itself, so I resorted to calling exit explicitly.  Will change that to
exit_with_hooks, for consistency's sake.

This wasn't the main point of my question, though, I could overcome the
problem and have a working nfsroot setup for quite some time.  Still I
feel like there should some way to transfer the lease acquired by the
PXE phase to the working system, and by that
  a) avoid hacking with dhclient-enter-hooks and
  b) avoid querying the DHCP server for the same lease several times
     (saving server resources, boot time and general hassle).

So this is more a philosophical question in the first round: do you
agree that such a feature would be desirable in some form, or do I
simply miss something obvious and it is already present?  Or maybe I'm
misguided and what I want is impractical or useless.

Thanks,
Feri.

>> Ferenc Wagner<wferi at niif.hu>  writes:
>>
>>> When booting an NFS rooted system, one generally has to go through three
>>> DHCP round trips:
>>>   1. PXE BIOS does DHCP to setup networking for downloading the kernel
>>>      and the initramfs image,
>>>   2. initramfs does DHCP to setup networking for mounting the NFS root,
>>>   3. the booting system does DHCP to set host and domain name and DNS
>>>      resolvers.
>>> But 3 is inherently problematic, because a cold-starting dhclient brings
>>> down its network interface, and NFS root can't tolerate that, the system
>>> deadlocks (cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553211)
>>>
>>> Now, it's technically possible to transfer the DHCP reply packet from
>>> the PXE phase down to dhclient.  It's also possible to create a lease
>>> file for dhclient by parsing this packet.  But, to my knowledge, there's
>>> no way to coax dhclient into skipping the PREINIT phase (that's where
>>> dhclient-script unconditionally downs the network interface), even
>>> though it's willing to skip discovery if it finds a valid lease.
>>>
>>> Also, while it may be possible to skip any interaction with the DHCP
>>> server if the valid lease (or the saved reply packet) contains all the
>>> options the client config needs, it should still be acted upon, as
>>> resolv.conf (as an example) should be set up.  If some information is
>>> missing, a DHCPINFORM would probably be the most appropriate choice.
>>>
>>> Now it seems to me that the nfsroot scenario can't be handled without
>>> tailoring dhclient-script, but I'd like to hear your opinion about the
>>> best handling of this whole problem domain.



More information about the dhcp-users mailing list