From owner-freebsd-stable@FreeBSD.ORG Wed Feb 17 19:22:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57DEC1065672 for ; Wed, 17 Feb 2010 19:22:55 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 3E9AC8FC0C for ; Wed, 17 Feb 2010 19:22:54 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta13.emeryville.ca.mail.comcast.net with comcast id j3Ed1d0090b6N64AD7NvKS; Wed, 17 Feb 2010 19:22:55 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta03.emeryville.ca.mail.comcast.net with comcast id j7Nu1d00E3S48mS8P7Nv9A; Wed, 17 Feb 2010 19:22:55 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C45B51E301A; Wed, 17 Feb 2010 11:22:53 -0800 (PST) Date: Wed, 17 Feb 2010 11:22:53 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100217192253.GA31689@icarus.home.lan> References: <20100217021136.GA10628@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: netboot issues, 8.0, mfsroot mount failure 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: Wed, 17 Feb 2010 19:22:55 -0000 On Tue, Feb 16, 2010 at 11:43:30PM -0500, Charles Sprickman wrote: > >Footnote: This is why I tell folks to zero out the first 8192 bytes of > >any disk they've previously installed FreeBSD on (even if the disk has > >no filesystems/slices on it). The way FreeBSD determines the size of > >the disk differs in RELENG_8; I believe GEOM "figures it out" on its own > >now, while previous releases relied on the "c" slice. The method I've > >recommended: do dd if=/dev/zero of=/dev/adX bs=512 count=16. > > Is it also advisable to blot out any old glabel stuff at the end of > the disk? What's the math to get that? Get a sector count for the > whole disk, set "bs" to 512 and "skip" to (sector count - 1)? I don't think the glabel data (which goes at the end of the disk) is relevant to the above problem I described. You can erase it if you want, but I doubt it's responsible for warnings like "Disk geometry does not match label!" or situations where a user is re-using a disk (that had its slices created on RELENG_7) on RELENG_8 and experiences problems. An alternative to the dd method might be to try "gpart destroy"; I haven't tried to see if relieves the problem. As far as how to erase the glabel metadata -- "glabel clear" is supposed to do this for you. What I don't know is whether or not addition of a glabel decreases what GEOM thinks the total size of the disk is, so I can't say for certain doing some math + zeroing the last sector of the disk would actually work. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |