Several minor annoyances on Current
Ian Lepore
ian at FreeBSD.org
Fri Jul 25 16:16:31 UTC 2014
On Fri, 2014-07-25 at 05:04 -0700, Beeblebrox wrote:
> Kurt Jaeger wrote:
>
> > Can you check whether one of your ethernet-ports has a double life
> > as IPMI port and that one sends out the DHCP ?
>
> No such setup. This is my workstation, with wake-on-lan and pxe-boot
> disabled in bios.
> Checking boot messages provides a little more insight - Its not one but
> *both* NIC's that look for DHCP. Also, this is before root gets mounted, so
> what's in rc.conf is irrelevant:
>
> Sending DHCP Discover packet from interface re0 (mac#)
> Sending DHCP Discover packet from interface re1 (mac#)
> Received DHCP Offer packet on re0 from 192.168.1.1 (accepted)
> Received DHCP Offer packet on re0 from 192.168.1.1 (ignored)
> Received DHCP Offer packet on re0 from 192.168.1.1 (ignored)
> Sending DHCP Request packet from interface re0 (mac#)
> Received DHCP Ack packet on re0 from 192.168.1.1 (accepted)
> DHCP timeout for interface re1
> re0 at 192.168.1.11 server 192.168.1.1
> subnet mask 255.255.255.0 router 192.168.1.1
> Adjusted interface re0
> Shutdown interface re1
> Trying to mount root from zfs:bsd []...
>
> I compile and use the same kernel for both host and pxe-booted diskless
> clients. So my kernel config file has
> options NFSCL # Network Filesystem Client
> options NFS_ROOT # NFS usable as /, requires NFSCL
> options BOOTP # Needed for non-btx PXE
> options BOOTP_NFSROOT # Needed for non-btx PXE
> It's probably what's causing this behavior. Kernel must receive IP before it
> can try and mount an NFS volume as root. However, I would have assumed that
> the "vfs.root.mountfrom=" setting in loader.conf would be read before such
> attempt...
>
I made changes last year that allowed vfs.root.mountfrom to
unconditionally override any path provided by the bootp/dhcp server.
While it overrides the server-provided path, it doesn't prevent
contacting the server (the override may be for a different nfs path).
See http://svnweb.freebsd.org/base?view=revision&revision=253847 for
details.
I didn't consider at the time that someone might want to avoid doing any
bootp configuration at all, but in retrospect I can think of several
good reasons to turn off bootp on a per-boot basis. The attached patch
provides a knob for that, I'll commit it if there are no objections.
-- Ian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bootp_disable.diff
Type: text/x-patch
Size: 470 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20140725/7d0da6b1/attachment.bin>
More information about the freebsd-current
mailing list