From owner-freebsd-stable@FreeBSD.ORG Mon Jun 15 16:14:08 2009 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 A5102106567F; Mon, 15 Jun 2009 16:14:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 626A78FC1C; Mon, 15 Jun 2009 16:14:08 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D842146B65; Mon, 15 Jun 2009 12:14:07 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id AED5B8A070; Mon, 15 Jun 2009 12:14:06 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, Daniel Eischen Date: Mon, 15 Jun 2009 08:53:34 -0400 User-Agent: KMail/1.9.7 References: <1407C6EC-873D-49AB-9F8C-6A4A6FFA9DC3@airwired.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906150853.35327.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 15 Jun 2009 12:14:06 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Dan Allen , "Paul B. Mahol" Subject: Re: Let's back out LOADER_ZFS_SUPPORT from STABLE 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: Mon, 15 Jun 2009 16:14:09 -0000 On Sunday 14 June 2009 7:08:50 pm Daniel Eischen wrote: > On Sun, 14 Jun 2009, Dan Allen wrote: > > > > > On 14 Jun 2009, at 1:27 AM, Daniel Eischen wrote: > > > >> From one of your older emails, you mention you are using > >> ad0s2a as / and ad0s2b as swap, and then say that ad0s2c > >> is unused (I may have the ad0s2 part wrong). But ad0s2c > >> should be the entire slice (or partition depending on > >> the wording you are used to). > >> > >> How about posting a relevent fdisk and disklabel (or > >> gpart show) so we can see what your slices and partitions > >> look like (fdisk /dev/ad0, disklabel /dev/ad0s2). > > > > ad0s2c is the entire slice as you thought it should be. > > > > Here is fdisk and bsdlabel /dev/ad0s2: > > > > ******* Working on device /dev/ad0 ******* > > parameters extracted from in-core disklabel are: > > cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl) > > > > Figures below won't work with BIOS for partitions not in cyl 1 > > parameters to be used for BIOS calculations are: > > cylinders=232581 heads=16 sectors/track=63 (1008 blks/cyl) > > > > Media sector size is 512 > > Warning: BIOS sector numbering starts with sector 1 > > Information from DOS bootblock is: > > The data for partition 1 is: > > sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) > > start 63, size 188747622 (92161 Meg), flag 0 > > beg: cyl 0/ head 1/ sector 1; > > end: cyl 1023/ head 10/ sector 63 > > The data for partition 2 is: > > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > > start 188747685, size 45688860 (22309 Meg), flag 80 (active) > > beg: cyl 1023/ head 255/ sector 63; > > end: cyl 1023/ head 14/ sector 63 > > The data for partition 3 is: > > > > The data for partition 4 is: > > > > > > > > > > # /dev/ad0s2: > > 8 partitions: > > # size offset fstype [fsize bsize bps/cpg] > > a: 43591708 2097152 4.2BSD 0 0 0 > > b: 2097152 0 swap > > c: 45688860 0 unused 0 0 # "raw" part, don't > > edit > > Seems weird to see swap at offset 0 and partition a after swap. > I wonder if that is screwing things up. And shouldn't the offset > for your first slice start at offset 188747685 (from fdisk)? swap at offset 0 will probably break. The first 16 sectors hold the BSD disklabel and boot code. FFS filesystems leave the first 16 sectors unused, so if you let 'a' start at 0, it actually starts at 16 and you are ok. However, if you let swap start at 0, it actually uses sector 0 and the first time you swap you will trash your filesystem label (yes, this arrangement is exceedingly lame). You could fix this by either letting 'a' come first or changing the swap to start at sector 16 instead of 0. -- John Baldwin