From owner-freebsd-stable@FreeBSD.ORG Fri Sep 11 17:27:33 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 D33411065676 for ; Fri, 11 Sep 2009 17:27:33 +0000 (UTC) (envelope-from shurd@sasktel.net) Received: from proton.sasknet.sk.ca (proton.sasknet.sk.ca [142.165.20.178]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8B78FC1E for ; Fri, 11 Sep 2009 17:27:33 +0000 (UTC) Received: from pps.filterd (proton [127.0.0.1]) by proton.sasknet.sk.ca (8.14.3/8.14.3) with SMTP id n8BHNH6s008087; Fri, 11 Sep 2009 11:27:32 -0600 Received: from bgmpomr2.sasknet.sk.ca (bgmpOMR2.sasknet.sk.ca [142.165.72.23]) by proton.sasknet.sk.ca with ESMTP id gqs14e150-1; Fri, 11 Sep 2009 11:27:32 -0600 Received: from ace.hurd.local (outgoing.bbsdev.net [76.202.204.46]) by bgmpomr2.sasknet.sk.ca (SaskTel eMessaging Service) with ESMTPA id <0KPT006RPHTU2Q10@bgmpomr2.sasknet.sk.ca>; Fri, 11 Sep 2009 11:27:32 -0600 (CST) Date: Fri, 11 Sep 2009 10:27:29 -0700 From: Stephen Hurd In-reply-to: To: Ivan Voras Message-id: <4AAA8881.7000609@sasktel.net> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT References: <4AAA1296.2080705@sasktel.net> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.22) Gecko/20090810 SeaMonkey/1.1.17 Mnenhy/0.7.6.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-09-11_12:2009-09-01, 2009-09-11, 2009-09-11 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0909110091 Cc: freebsd-stable@freebsd.org Subject: Re: 8.0-B4 gstripe / GEOM_PART_* upgrade woes 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, 11 Sep 2009 17:27:33 -0000 Ivan Voras wrote: > An interesting problem. I presume that in either case (gpart or > GEOM_BSD/MBR) the output of "gstripe status" is the same? Only the > interpretation of the partition tables is problematic? Yes, but the output of gstripe list is different in the mode lines... for GEOM_PART, the mode is r0w0e0 in all consumers and for GEOM_*, the mode is r3w3e5. > What is the expected ("good") structure of the partitions/file > systems? Do you have a single MBR partition and inside it multiple BSD > partitions? What are their partition types? Not sure the correct way to get the info, but the output of fdisk and bsdlabel follow: ==== START of fdisk ==== > fdisk /dev/stripe/raid0 ******* Working on device /dev/stripe/raid0 ******* parameters extracted from in-core disklabel are: cylinders=5219 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=5219 heads=255 sectors/track=63 (16065 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: The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 0, size 50000 (24 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 ==== END OF fdisk ==== ==== START OF bsdlabel ==== > bsdlabel /dev/stripe/raid0 # /dev/stripe/raid0: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 16777216 16 4.2BSD 2048 16384 28552 b: 16777216 16777232 4.2BSD 2048 16384 28552 c: 20964825 8385930 unused 0 0 # "raw" part, don't edit d: 50302960 33554448 4.2BSD 2048 16384 28552 bsdlabel: partition c doesn't start at 0! bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities ==== END OF bsdlabel ==== Now that I look at the bsdlabel output, I vaugely recall that I couldn't get c correct...