From owner-freebsd-current@FreeBSD.ORG Fri Jul 25 16:16:31 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9569DE5E for ; Fri, 25 Jul 2014 16:16:31 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 539D22277 for ; Fri, 25 Jul 2014 16:16:30 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XAhsA-000L3B-Qc; Fri, 25 Jul 2014 15:57:31 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6PFvTYg001274; Fri, 25 Jul 2014 09:57:29 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+SFTR9z3Md4pn/sBkUsfR+ X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Several minor annoyances on Current From: Ian Lepore To: Beeblebrox In-Reply-To: <1406289867854-5931678.post@n5.nabble.com> References: <1406282699515-5931653.post@n5.nabble.com> <1406287169575-5931665.post@n5.nabble.com> <1406289867854-5931678.post@n5.nabble.com> Content-Type: multipart/mixed; boundary="=-TBR0ovB1JJcy/N8kArLS" Date: Fri, 25 Jul 2014 09:57:28 -0600 Message-ID: <1406303848.56408.16.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:16:31 -0000 --=-TBR0ovB1JJcy/N8kArLS Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 --=-TBR0ovB1JJcy/N8kArLS Content-Disposition: inline; filename="bootp_disable.diff" Content-Type: text/x-patch; name="bootp_disable.diff"; charset="us-ascii" Content-Transfer-Encoding: 7bit Index: sys/nfs/bootp_subr.c =================================================================== --- sys/nfs/bootp_subr.c (revision 268986) +++ sys/nfs/bootp_subr.c (working copy) @@ -1551,8 +1551,11 @@ bootpc_init(void) struct nfsv3_diskless *nd; struct thread *td; int timeout; - int delay; + int delay, disable; + if (TUNABLE_INT_FETCH("vfs.nfs.bootp_disable", &disable) && disable) + return; + timeout = BOOTP_IFACE_WAIT_TIMEOUT * hz; delay = hz / 10; --=-TBR0ovB1JJcy/N8kArLS--