From owner-freebsd-stable@FreeBSD.ORG Fri Mar 10 06:31:04 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 624F616A420 for ; Fri, 10 Mar 2006 06:31:04 +0000 (GMT) (envelope-from sergey@road.omskelecom.ru) Received: from mx.road.omskelecom.ru (ftp.road.omskelecom.ru [195.162.36.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE66D43D58 for ; Fri, 10 Mar 2006 06:31:02 +0000 (GMT) (envelope-from sergey@road.omskelecom.ru) From: sergey akifiev Date: Fri, 10 Mar 2006 12:30:58 +0600 To: freebsd-stable@freebsd.org Message-ID: <20060310063058.GE69429@ugai.uvd-omsk.su> Mail-Followup-To: freebsd-stable@freebsd.org References: <20060306084222.GE57165@ugai.uvd-omsk.su> <20060306092743.GA18697@xor.obsecurity.org> <20060306105507.GF57165@ugai.uvd-omsk.su> <20060306210034.GA50522@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20060306210034.GA50522@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.88/1320/Fri Mar 10 00:11:14 2006 on ugai.uvd-omsk.su X-Virus-Status: Clean Subject: Re: 6.1-PRERELEASE nfs root troubles X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2006 06:31:04 -0000 On Mon, Mar 06, 2006 at 04:00:34PM -0500, Kris Kennaway wrote: > Thanks :) I netboot many machines on 6.1 and don't see this, so perhaps it it due to your use of the BOOTP* options: > > options BOOTP # Use BOOTP to obtain IP address/hostname > # Requires NFSCLIENT and NFS_ROOT > options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info > options BOOTP_NFSV3 # Use NFS v3 to NFS mount root > options BOOTP_COMPAT # Workaround for broken bootp daemons. seems, that this issue isn't connected with BOOT* options at all. my test host, holding diskless root is an i686 machine and diskless client is an old i586 box. it seems, that some i686-optimized binary sneaked into diskless client's root. i've found this by booting that kernel on dual-xeon server lieng around here ;-) but is still cannot understand, how this can be connected with this trap... -- WBFH: -error IL2: =SB=error SGA16-RIPE